Copyright: © Copyright Agilent Technologies, 2000


VXI Overview

If you've been around electronics very long, you know "rack and stack" instruments have been a mainstay in the industry for years. Much of their success is due to a widely used interface, IEEE-488. Developed by Hewlett-Packard in the mid-1970's, this interface allows you easily to connect your instruments using a remote computer.

In the late 1980's, Hewlett-Packard offered a standard instrument language that was quickly adopted by the Test and Measurement industry as SCPI — Standard Commands for Programmable Instrumentation — to eliminate the multitude of proprietary instrument programming languages available from instrument vendors. During this time, HP and other instrument manufacturers produced a growing number of proprietary HP-IB modular instrument products. These instruments could be integrated into test systems to provide switching, measurements and signal source capabilities. However few of these modular products were compatible.

The VXIbus standard addressed this problem of incompatibility. Because it changes the way we think about electronics test, there's still some confusion about how to apply the VXIbus standard, how complex it is, and how it fits in with existing rack and stack instruments. With the success of the VXIbus standard, other standards — like VXIplug&play and SCPI — are emerging to improve the usefulness of VXIbus technology in electronics testing.

In this introduction to VXI technology, we'll provide you with a basic understanding of VXIbus, SCPI, and VXIplug&play — and explain some of the advantages of these standards. We will not tell you they are the answer to every problem, but will show you how to integrate these modular products into your current test system. We'll also help you understand the tradeoffs in selecting various VXI devices. Please understand this is not a manual for any specific VXI instrument, but rather an introduction to overall VXI technology.

We're pleased to be a leader in VXIbus, SCPI, and VXIplug&play technologies. We think you'll see the advantages of these standards in your test system environments.


VXIbus: The Test and Measurement Standard

The History of VXIbus

During the late 1970s and 1980s, numerous electronic instrument companies were producing their own proprietary cardcage systems. The manufacturers recognized the advantages of cardcage and IAC (Instrument-On-A-Card) systems, but they were using vastly different approaches. At the same time, the US Air Force created a program to design a single IAC standard that would result in substantially smaller electronic equipment.

In April 1987, five companies — Hewlett-Packard, Tektronix, Colorado Data Systems, Racal-Dana, and Wavetek — started discussions aimed at creating an IAC standard that would benefit both the commercial and military test communities. The companies formed the "VXIbus Consortium" and met for three months of intense technical discussions. An initial draft, the VXIbus System Specification, was released on July 14, 1987.

Like most new things, the specification has undergone several changes. Revision 1.3 was released in July 1989. The specification was submitted to the IEEE for consideration as a standard. In addition, the U.S. Air Force has incorporated the VXIbus specification into its MATE (Modular Automated Test Equipment) program.

Goals of the VXIbus Consortium

The members of the VXIbus Consortium had a lot of experience with IAC systems. They understood their benefits — increased test throughput, smaller instruments, reduced cost, etc. They wanted to create a technically sound standard that would bring IAC systems into the "next generation." That would free up design engineers to do what they do best — bring new technologies to market. The result would be products of greater innovation, quality and diversity.

HP-IB and VMEbus: The Foundation for VXIbus

The VXIbus consortium members recognized Hewlett-Packard's HP-IB (IEEE-488) and VMEbus as the two most popular standards for instrumentation. They decided to take the best from these standards and add more features to create the best possible IAC standard.


What is HP-IB?

In the early 1970's, Hewlett-Packard invented an 8-bit parallel interface — HP-IB. It allowed rack and stack instruments to communicate with each other and with a host computer. In 1975, HP-IB was adopted by the IEEE as standard IEEE-488. Today, it is the leading interface used in automated test systems built on individual instruments. It is simple, flexible, and used by nearly all instrument manufacturers.

HP-IB is a widespread standard — it allows you to connect instruments from several manufacturers to a host computer (controller), and thus build an automated, integrated test system. Normally, you don't have to worry about how information is passed between the devices. Your only concern is the content of the information, whether it be ASCII or binary instructions to an instrument, or ASCII or binary results from an instrument.

A good way to think of HP-IB instruments is as electronic devices that operate by themselves. They have communication intelligence, and may also perform sophisticated data capture and analysis. An example is a digital multimeter. Using HP-IB, you can send the multimeter a sequence of ASCII strings that instruct it to take a burst of 1000 readings. You may also send it commands telling it to calculate statistical functions like minimum, maximum, and standard deviation on the readings. Then you can bring only those resulting values back to the computer.

One limitation of HP-IB has been a maximum data transfer rate of about 1 Mbyte per second. This is usually not a problem, since most applications are limited by the speed of the measurement circuits, or by the switch closure and settling time required to route signals. However, it can become a problem with high-speed digitizing, digital inputs/outputs, or if large amounts of data must be transferred from an instrument to the computer for specialized processing. Furthermore, the HP-IB protocol limits the transfer speed to that of the slowest device on the bus.


What is VMEbus?

While HP-IB is the most popular electronic instrument interface, VMEbus is widely used in microcomputer systems. The VMEbus specification was released in August 1982, and approved by IEEE and ANSI in 1987.

You can think of VMEbus as an interface with two components — mechanical and logical. The mechanical portion specifies the physical dimensions of plug-in boards, backplanes, subracks, etc. (The form factor of the plug-in boards is commonly known as the Eurocard format.) The logical portion of the interface describes how functional modules (in this case, plug-in cards) communicate with each other. A major objective of VME-bus is to allow communication between two devices without disturbing the internal activities of other devices in the system. VMEbus systems can have multiple microprocessors on the same backplane.

A VMEbus sytem: Potential for High Speed and Multiple Processors

One strength of VMEbus is it allows high-speed communication between devices (which we use interchangeably here with "modules"). The specification was originally intended for microcomputer systems. As instrument speeds increased and printed circuit board sizes decreased, interest grew in bringing electronic instruments into the system. However, this brought out two shortcomings of VMEbus: the electrical environment, designed for digital communication, is too "noisy" for precise analog measurements, and the programming needed for high-speed communication has to be done with low-level register reads and writes.


VXIbus: The Best of Both Worlds, and More!

Members of the VXIbus Consortium realized that for the VXIbus standard to be successful, it must answer two major challenges in instrumentation: communication speed and integration. The HP-IB and VMEbus specifications held the answers to both problems. A third challenge solved by the Consortium was to devise a well-defined environment in which different vendors' products can operate together properly. The result is the VXIbus (VMEbus Extensions for Instrumentation).

Taking the Best from HP-IB & VMEbus.

The VMEbus specification, originally designed for microcomputers, has a great potential for high-speed device-to-device communication. This can increase the throughput of your test system considerably. And HP-IB is well known for its ease of integration, which helps you to build your test system faster. So the two main challenges — speed and integration — were answered. Although the HP-IB and VMEbus standards have different bus communication styles, VXIbus defines two different devices to take advantage of these styles.

Remember that HP-IB instruments are easy to use. You simply connect the cable and program the instruments in whatever language they require. In VXIbus systems, the counterpart to HP-IB instruments are "Message-Based Devices." They are easy to integrate into a system and communicate at a high level using ASCII characters. Like HP-IB instruments, Message-Based Devices can contain significant intelligence and data processing capabilities. Like instruments on an HP-IB bus, however, Message-Based Devices can be limited when it comes to high-speed data transfer.

VXIbus: High Speed and Multiple Processors

The outstanding feature of VMEbus devices is they can move data between themselves very fast. The VXIbus specification defines "Register-Based Devices" as the analog to VMEbus devices. These devices communicate at a lower, more basic level than Message-Based Devices and so can attain greater transfer speeds. Programming a Register-Based Device involves writing to and reading from individual registers on the device.

More Features of VXIbus Systems.

The VXIbus Consortium fully defined the operating environment for VXIbus modules. All VXIbus mainframes must state how much power and cooling they provide. And all VXIbus modules must state how much power and cooling they require.Also, there are strict limits on how much conducted and radiated interference is allowed between mod-ules. These parameters allow you to configure a workable system easily.

Two special functions must be performed in every VXIbus system. The first, Slot 0, takes care of backplane management. Slot 0 is a unique physical location in every VXIbus mainframe. Signals from this slot must include things like clock sources, arbitration for data movement across the backplane, etc. The module that goes into this slot must perform these hardware functions in addition to its normal functions. If you're familiar with VMEbus systems, you probably recognize that this is very similar to VME's "Slot 1 Device." The Slot 0 device relieves you of the burden of managing data flow across the backplane.

VXIbus Additional Features

The second special function in a VXIbus system is the Resource Manager. The best way to think of the Resource Manager is as a computer program. This program configures the modules for proper operation whenever the system is powered on or reset. This means you can build your test system software from a known starting point. The Resource Manager is not involved with the VXIbus system once normal operation begins


SCPI: The Standardized Programming Language

With the rapid growth of computer-controlled instruments, Hewlett Packard recognized the need for a common instrumentation language. Therefore, in the late 1980's, Hewlett-Packard invented TMSL (Test and Measurement Systems Language) and offered to make it an open standard. TMSL itself was based on industry standards wherever possible, including IEEE-488.2 and IEEE-754. In April 1990, this standard was accepted by the industry, and renamed SCPI (Standard Commands for Programmable Instrumentation). You now have to learn only this single instrument programming language, regardless of whose digital multimeter (or other similar instrument) you purchase. With this standardized programming language for VXIbus instrumentation in place, you can reduce your test system programming time!


VXIplug&play: The NEW Standard for Test and Measurement

VXIbus was a significant effort to standardize modular instrumentation. It provided an open environment where any vendor's modules would plug into any VXI mainframe. Users could expect the module to fit the slot size and be adequately powered and cooled. However, VXIbus didn't address the need to integrate a system that was truly vendor independent and makes it easily usable. Wouldn't it be nice if there were a common look and feel, or a standard soft front panel for given instrument types from various vendors? Wouldn't it be great if you could develop your application program on a PC and execute it on a UNIX platform? Or, what about instrument drivers? An industry standard set of drivers would eliminate custom driver design issues. Hewlett-Packard is an active member in the VXIplug&play System Alliance to address these challenges.

What is VXIplug&play?

VXIplug&play is a term indicating conformance to a new set of system-level standards, produced by the VXI-plug& play Systems Alliance. Hewlett-Packard joined the VXIplug&play Alliance in 1994 in support of the Alliance's charter: "to improve the effectiveness of VXI-based solutions by increasing ease-of-use and improving the interoperability of multi-vendor VXI systems." The goal of the Alliance is to achieve interoperability of mainframes, computers, instruments, and software through open, multivendor standards and practices. The Alliance consists of vendors actively involved with end-users to produce instrumentation systems that meet this goal. Additionally, the Alliance is open to all vendors and users as a forum for working together to make VXI technology easier to use.

Thanks to the work of the Alliance, VXIplug&play components integrate easily. The new standards apply to instrument drivers, soft front panels, installation packages, documentation, technical support, application development environments, as well as many other areas for instrument system integration. As with the VXIbus standard, revisions to VXIplug&play will continue to reduce your dependence on any single vendor and simplify your job of system design and implementation.


What does VXIplug&play offer?

VXIplug&play improves productivity, portability, and interoperability for both vendors and end-users.

Productivity: Use soft front panels to operate and evaluate instrument operation within minutes.

Portability: Communicate with instruments via any controller/ computer interface supported by the VISA I/O library.

Interoperability: Develop application programs portable across computer platforms and I/O interfaces. Add new programs without having to rewrite existing ones.  With vendors and end-users working together, the real needs of system integration continue to be analyzed, defined, and implemented.


What Do VXIbus, SCPI, and VXIplug&play Mean to You?

The VXIbus, SCPI, and VXIplug&play standards can improve your test system's speed and flexibility, lower your product "life cycle" cost, protect your investment, and provide a choice of vendors' products that will work together in your test system.   What these mean to you are:

•	Open standards

•	Higher test system throughput

•	Different Priorities Maximum Throughput

•	A True Upgrade Path

•	Easy Integration with Rack and Stack

•	Smaller Test Systems

•	Access to Switching Modules

•	Long-Term Software Protection

•	Multi-Vendor Interoperability


Open Standards

VXIbus, SCPI, and VXIplug&play are truly open standards. So far, over 200 different manufacturers have received identification codes from the VXIbus Consortium, and hundreds of different instruments are available. This multi-vendor environment ensures that your investment in VXIbus products will be protected long into the future. If one manufacturer's instrument becomes obsolete, a replacement should be available from another. Also, there will be many "niche" manufacturers willing to provide specialty modules — just as in the computer industry.

Because of the open standards, instrument manufacturers can provide VXI products with the benefits of standardized architecture, instrument programming language, and I/O communication. The backplane pinouts and communication techniques are already defined for you. Power and cooling capabilities are completely specified. Also, electrical interference limits have been set, so you know your module will have a "quiet" environment. The VXIbus specification defines all of these, and takes care of the hardware specifications for any VXI system. The VXIplug&play System Alliance completes the standardization process with specification for the operating system or "framework," instrument drivers and I/O software. VXIbus and VXIplug&play, working together, give you all the tools and guidelines needed to successfully design a custom VXI compatible module for a unique function, build a new VXI test system, or upgrade your existing system.


Higher Test System Throughput

Increased test system throughput gives you a great competitive edge by lowering testing and manufacturing costs. The VXIbus backplane has a theoretical data transfer limit of 40 Mbytes per second. Normally, the backplane will not be a bottleneck for your data transfer. The not-so-obvious advantage of the VXIbus is its potential for distributed intelligence, which leads to increased system throughput. Because of its VME-bus background, VXIbus can deal with multiple microprocessors on the backplane existing within a shared memory architecture. Arbitrating data transfers on the backplane allows for a higher data bandwidth than any single device in the system can achieve. Multiple levels of priority allow critical processes to interrupt and use resources only when they're required.


Different Priorities Maximum Throughput

How can this help you? Let's say you have an embedded computer that's transferring a large block of readings from a digitizer into the computer's memory over the data bus. Simultaneously, another instrument like a counter might be using the data bus to send a value to the controller every few milliseconds. At the same time, another intelligent device might be monitoring several channels of voltage and internally performing limit checks. If a condition goes out of limit, this device could request the data bus at a higher priority than the other devices, and send only the failure data to the computer for immediate action. Together, these multiple devices, with their different priorities, can more efficiently fill the data bus. This makes for higher overall system throughput.


VXIbus: A True Upgrade Path

Another great feature of the VXIbus is a true migration or upgrade path. This allows you to use your current hardware and software in future test systems. Suppose your current application is fairly simple: scan 15 channels of voltage, measure the frequency of two signals and provide low-level power for a current loop. This application could be easily and inexpensively done by a system based on small VXIbus modules. Your testing needs may expand in the future so that you'll need more high-performance instruments such as a high-speed digitizer or signal generator. These instruments may only be available as larger and more complex VXIbus modules. But all your smaller VXIbus modules will easily fit right into the new, larger system! Also, VMEbus devices you're currently using, or plan to use, can be integrated into a VXIbus system. Your imagination is the only limit on the size and complexity of your system.


Easy Integration with Rack and Stack

VXIbus and VXIplug&play systems can coexist perfectly with HP-IB test systems. You can use the resources from both without being limited to one type of system. In fact, many of your test systems probably will be a mix of VXIbus and non-VXI instruments. For example, a test system may need VXIbus to solve a throughput bottleneck, and also a very high accuracy measurement from a network analyzer that is available only as a standalone instrument.

Another common scenario might be a VXIbus mainframe full of instruments controlled by a computer. The computer might be embedded in the VXIbus mainframe or external to it. At the same time, this computer could easily control several large programmable power supplies via HP-IB, and perhaps monitor transducers or data links via RS-232.

Both HP-IB and non-VXI instruments can be programmed exactly like VXIplug&play instruments, by adapting VXIplug&play instrument driver technology and using SCPI commands with either the VISA I/O Library or HP SICL (Standard Instrument Control Library).


Smaller Test Systems

Probably the most obvious advantage of VXIbus systems is the significant downsizing of test systems. Much of the downsizing results from using common power supplies and eliminating front panels. This benefit has been very important to military users due to their extremely large test systems, and continues to grow in the commercial world as devices increase in electronic content and complexity.


Access to Switching Modules

Many people are introduced to VXI because of their need for signal routing (switching). Almost every test application requires some sort of signal routing, and VXI offers many more choices than traditional rack and stack. As more instruments become available, the importance of VXI in testing continues to grow.


Long-Term Software Protection

VXIbus is an excellent solution to the problem of hardware compatibility — i.e., protecting your hardware investment. But software compatibility, software development productivity, and protecting your investment in software are equally important issues. In a lot of applications, the cost of test system software is actually greater than the cost of the hardware!

Development of the VXIbus specifications increased awareness of software incompatibility issues. SCPI (Standard Commands for Programmable Instrumentation) can now help you protect your software investment with one standardized programming language for VXIbus instrumentation.


Multi-Vendor Interoperability

VXIplug&play emerged not only to address software issues, but also to define standards at a complete system-level. Successfully integrating a multi-vendor VXI system requires hardware working together at the electrical and mechanical level. The software used to control the hardware must also work together. In large, complex test systems, determining the "framework" or platform and then finding components that work together may be an integrator's greatest challenge. VXIplug&play becomes an excellent solution for integrating your VXI system into a successful multivendor environment.

With the VXIplug&play concept, you designate a standard system "framework" or platform based on the system software you intend to use (i.e., Microsoft ® Windows 3.1/NT/95, or HP-UX*). By using the framework designation when you choose the rest of your system components, your VXIplug&play compliant components will be easy to use and easy to integrate into your test system. No longer should the preference for aparticular software or hardware component need to lock you out of a system or platform. Another benefit of VXIplug&play is its portability between the Windows and HP-UX environments. This means that your application written on HP-UX can run under Windows with a simple recompile of the code. VXIplug&play gives you even more flexibility in meeting your test system needs in the multi-vendor environment.


The VXIbus Standard: More Details

In this section, we'll give you more detailed information about VXIbus systems. This should answer some common questions you may have about VXIbus, and help you "speak VXI" if you wish to pursue further information.

Instrumentation Environment

The VXIbus is an open standard that many manufacturers are now using to develop a wide variety of products. This means the specification must provide a well-defined environment to guarantee proper system operation. To define an environment for a variety of high-performance instruments, the specification addresses several important issues in physical and electrical compatibility.

Module Sizes

One requirement for physical compatibility is the size of plug-in modules. The VMEbus standard defined two small module sizes. They're known as A-Size and B-Size modules in VXIbus. These modules are fairly compact; it's difficult to fit multi-functional analog instruments onto them.

So the VXIbus Consortium extended the VMEbus specification for module sizes — it defined two larger modules, C- and D-Size. These four module sizes allow you to make a number of price and performance tradeoffs so you can optimize your test system.

The most common card sizes are B- and C-Size. As with any system, PC-board space costs money. The B-Size format gives you an excellent tradeoff in cost and complexity, and is very useful for simpler, lower-cost instruments. Instruments that make a good fit for B-Size modules include relay multiplexers, some voltmeters and counters, and 4-channel digital-to-analog converters.

C-Size is a good size for more complex instruments requiring extra space for sophisticated circuitry or computation hardware. Since A- and B-Sizes came from the VMEbus, they retain the module-to-module spacing of 0.8 inches (2 cm) specified by VMEbus. Because C-Size is defined by VXIbus, it uses a larger spacing of 1.2 inches (3 cm). This gives C-Size modules better shielding from electrical interference, and therefore better measurement sensitivity and accuracy.

3457A DMM and its VXIbus C-size equivalent

Some examples of instruments that fit the C-Size format are high-performance multimeters, function generators, high-speed digitizers and high point count switches. A-Size cards are too small for precision instruments, given current measurement technology. Still, they are a good size for communication interfaces to the non-VXIbus world.

The D-Size format is useful in specialized applications, but it does result in significantly higher cost and increased rack space. As a result, almost all manufacturers are using multiple C-Size slots for complex instruments instead of putting them onto D-Size modules.


VXIbus Connectors

Closely related to module sizes are the backplane connectors. All modules must have at least one 96-pin connector, known as P1. All the pins on P1 are completely defined by the VMEbus specification. These definitions are maintained in VXIbus. P1 contains all the necessary lines for 16-bit data transfer, handshaking, bus arbitration, and interrupt support.

It's possible to add the optional P2 connector on B-Size and larger modules. This will expand the data transfer bus and provide a local bus for high-speed module-to-module communication. On D-size cards, you can add another optional connector, P3, which adds resources for specialized instrumentation. When combined with multiple module sizes, this range of connectors allows you to optimize your test system with various price and performance tradeoffs.

P1

•	16 bit Data Transfer Bus

•	Arbitration Bus

•	Prioritized Interrupt Bus

P2 (optional)

•	Increase width of Data Transfer Bus

•	12-line Local Bus

•	TTL & ECL Trigger Buses

•	10 MHz Clock Bus

•	Power Distribution Bus

P3 (optional)

•	Increase width of Local Bus

•	Increase width of ECL Trigger Bus

•	100 MHz Clock Bus

•	ECL Star Bus

•	Expand Power Distribution Bus


VXIbus Modules

The second major issue of compatibility addressed by the VXIbus specification is the mainframe environment. VXIbus product vendors need to know exactly what type of environment their module will be used in, so they can design, test, and specify it properly.

This means you can have great confidence that VXIbus systems — including those comprised of different vendors' modules — will function properly.

All VXIbus mainframes must specify how much steady-state and dynamic current they provide at different voltage levels. Also, mainframes must specify how much cooling, on a per-slot basis, they provide. VXIbus plug-in modules must provide corresponding information about their own requirements.

Plug-in modules must also specify both high-frequency emission and susceptibility. The VXIbus specification sets strict limits for the amount of interference a device may emit. Conversely, the device's operation must not be affected by neighboring modules operating within interference limits. These limits and tests apply to both radiated and conducted signals.


VXIbus Devices and Communication

In this booklet, you'll noticed the term "device" used often. The simplest way to think of a device is as a plug-in module, or card. In VXIbus systems, every device must have a unique address from 0 to 255, called its Logical Address. This distinguishes it from other devices in the system.

Every VXIbus device is granted 64 absolute addresses on the backplane. You can think of this as 64 bytes of RAM on the device that can be addressed and accessed by other devices in the system. This little block of memory serves two main purposes — it contains information about the device and its communication capabilities, and it's also the location where all required communication with the device takes place.


VXIbus device registers

The device's Logical Address determines the address of the "information and communication memory" within a VXIbus system. This 64-byte chunk of dedicated memory con-tains the device's "Configuration Registers" and "Communication Registers."

The VXIbus specification defines four types of devices — Register-Based, Message-Based, Memory, and Extended.

Memory devices are just specialized Register-Based Devices that are optimized to hold and move large amounts of data. Extended Devices are currently reserved, and provide a growth path for new types of devices in the future.

Register-Based Devices

In the first section of this booklet, we said that VXIbus Register-Based Devices communicate much like VMEbus Devices. This means that they're programmed at a low level using binary information. The obvious advantage of this is speed — Register-Based Devices communicate literally at the level of direct hardware manipulation. This high-speed communication can lead to much greater test system throughput.

All types of devices in a VXIbus system must have some sort of communication interface to the VXIbus backplane.

One advantage of Register-Based Devices is that this interface is very simple, and thus small and low in cost.

Register-based communication

The Register-Based Device is ideal for simple cards such as switches, multiplexers, basic DACs, etc. There's little reason to put a large, expensive communication interface on these devices. The register-based interface is also a good choice for devices that may need to move large amounts of information across the VXIbus backplane at very high speeds — for example, high-speed digitizers and high-speed digital I/O cards.

You might think Register-Based Devices are limited to being very simple devices. However, this is not the case. For example, a register-based digital multimeter may communicate with other devices using low-level binary commands, but it could also have an internal micro-processor for, say, sophisticated measurement control and self-diagnostics.

A lot of people like Register-Based modules because of their low cost, but don't want to have to program them with low-level binary commands.

Paths for registered-based communication

VXIbus answers this concern with a concept called Commanders and Servants (not a video game). A device that contains the intelligence to operate a Register-Based Device can be configured as a Commander to that Register-Based Device.

You send high-level ASCII commands to the Commander, it interprets them, and then sends the necessary binary information to the Register-Based Servant. In this mode, you program Register-Based Devices exactly as if they are Message-Based Devices. Figure 12 shows the options available for programming Register-Based Devices.


Message-Based Devices

Message-Based Devices, in contrast to Register-Based Devices, communicate at a very high level using ASCII characters. A good analogy for these devices is standalone HP-IB instruments. Message-Based Devices are very easy to integrate into VXIbus systems. This is especially important in systems comprised of modules supplied by different vendors.

Message-Based Devices communicate with each other with a well-defined set of rules known as "Word Serial Protocol." This asynchronous protocol defines the handshaking necessary to move commands and data between devices.

Message-based communcation

One advantage of Word Serial Protocol is that it hides compatibility concerns from you, the user. That's why Message-Based Devices are easy to integrate into a system. To program them, you simply send and retrieve high-level ASCII characters. The characters you send must be in the device's specific language — but you don't have to worry about module-specific registers, binary reading and writing, etc.

Two tradeoffs are required to have this ease of use. First, the communication interface required to implement the Word Serial Protocol is com-plex. This means it takes up more "real estate" on the circuit board than the communication interface of a Register-Based Device. Hence, a Message-Based Device will always cost more than an equivalent Register-Based Device. Also, because of the space committed to communication rather than measurement circuitry, Message-Based instruments will generally be on C-Size or larger modules.

Second, the communication speed between devices is lower. It's roughly equal to that of HP-IB. However, most sophisticated devices will have on-board data processing, so they may only need to pass a final result from the device to the controller. An example of this is an oscilloscope that digitizes a waveform and then automatically measures rise time. Only the rise time is passed from the instrument, not all the digitized readings.


More on Communications

The ability to communicate between devices, VXIbus back-plane, and controllers or computers is an integral part of any VXIbus test system. We've already defined the two types of devices — Register and Message — and how they are set up for communication. How can we improve data transfer, or take measurements for tests requiring transfers of large amounts of data? How can we continue to grow test sys-tems and keep cost low? With new developments in external interfaces and both external and embedded controllers, the rules are changing and more options are being created for answering these questions.

As noted earlier, one limitation of HP-IB is its maximum data transfer rate: about 1 Mbyte per second. However, if this meets your application needs, you can look to other areas for growth. For instance, the LAN/HP-IB Gateway, with new measurement server software, allows test systems to operate on thin or twisted pair LANs. It is particularly useful when the device under test is in a protective or environmental chamber some distance away from the controller; engineers can follow the test run's progress from a workstation at their desks. Another advantage is its ability to create measurement servers on the network. This allows you to use a measurement server to collect test data and analyze it from multiple locations.


External Interfaces

In addition to the popular HP-IB interface and HP-IB Command Module, other external interfaces offer even more possibilities. Specifically, two products — VXLink and MXIbus — connect your PC- or UNIX-based controllers directly to the VXI backplane without going through the HP-IB interface. With VXLink, the VXLink module plugs into slot 0, and so does not require a separate command module. VXLink-interfaced systems typically outperform VXI systems configured with an HP-IB command module. VXLink includes complete development software tools to reduce the time and effort required to develop and integrate your system. With MXIbus, a VXIbus extender module plugs into slot 0 of the mainframe and connects to the MXIbus interface in the external controller. When used with high-powered computers, you get the advantages of the external controller, plus the speed and throughput of direct memory-mapped access to the VXI backplane. With these advances in external interfaces, VXIbus vendors continue to push the limits for faster and more configurable communication tools.


Embedded vs. External Controllers

Whether you choose an embedded or external controller will depend on your test system needs. To select the best controller, consider several factors: operating system, throughput, ease of use, physical size, configuration flexibility, and cost. For example, if your application requires the greatest possible throughput, a VXI embedded PA-RISC controller using HP-UX — the HP 9000 Series 700 — may best fit your needs. Using this controller in conjunction with VXI devices that use high-speed register-level communication gives you maximum throughput.

When space is at a premium in your test system set-up, embedded controllers are extremely valuable. Embedded controllers integrate high functionality into small modules for use within either B- or C-size VXI mainframes. Embed-ding the controller in the VXI chassis allows direct computer access of other VXI devices, system memory, and triggers as though they were part of the controller hardware. You get performance and computer access to VXI devices while still conserving space.

With external controllers, you can get performance ranging from low-cost workstations to the full computing power of the best "personal supercomputer"! Most external controllers also offer the networking functionality you may need, plus plenty of built-in interfaces and high-performance graphics. For example, if you need easy access to your controller as you develop a test application and cost is a primary concern, an external controller — PC-based or UNIX-based — may better fit your needs. An external controller requires the use of an interface to connect to the VXI mainframe. Another excellent advantage of an external controller is the ability to cycle the VXIbus mainframe without having to reboot the operating system. If you have custom VXI modules as part of your test system, this can be very important during application development. With the fast-paced, changing technology of the computer industry, you benefit greatly with an external controller. This choice allows you to upgrade your computing power and performance as your test system requires.


How To Use This Help File

To do this...	Click...
Display or hide the navigation pane (Contents, Index, and Search tabs)...
Display the documentation roadmap...
Browse through the online topics...
View the Table of Contents…
Display the online help index...
Search for a word or phrase...
Display a history of topics that you’ve visited…
To print a single topic...
To print an entire Book…	(in the Table of Contents)
To change the displayed font size…


Acknowledgements

The following products are mentioned in one or more places in the Agilent 89600-series documentation.

Product	Acknowledgement
Adobe® and Acrobat®	These products are trademarks of Adobe Systems Incorporated.
Microsoft®, Windows NT®, Windows®, and MS Windows®	These products are U.S. registered trademarks of Microsoft Corporation.
MS Excel, MS Word, MS Office, VBScript	These products are products of Microsoft Corporation.
MATLAB	MATLAB is a product of The MathWorks, Inc.


The Documentation Roadmap is not installed on your system.


1999-2001, Agilent Technologies


This documentation is not installed on your system.


The product note "Agilent 89601A Vector Signal Analyzer Software: Ultrabroadband vector signal analyzer measurements using the Agilent Infiniium oscilloscopes" was not available at the time this product shipped.

You can download the file from the 89600 web page, http://www.agilent/com/find/89600.

Put the file (5988-4096EN.pdf) in the directory "Program Files/Agilent/89600/help". After the file is in place, the 89600 help will link directly to the PDF.